feat(thread_aware_core): add the stable core crate for thread-aware state - #643

Summary

Adds thread_aware_core, the stable vocabulary that thread-aware libraries share. Nothing
else in the workspace changes.

• ThreadAware notifies a value that it has moved, via
  relocate(source: Option<&Thread>, destination: &Thread). The call is advisory: a value
  must remain correct if it is never called, called twice, or called with a Thread it has
  never seen. That single property is what lets the method be infallible and lets a runtime
  call it opportunistically.
• Thread records where a value runs — Owner (which runtime owns it), a
  std::thread::ThreadId, and NumaNode (the memory closest to that thread). Fields are
  private and read through accessors.
• Owner identity is assigned, not supplied: every new owner is unique, so two runtimes
  alive at once cannot collide. It also reports min_threads, the smallest number of threads
  its runtime runs, so a value can pre-size per-thread state before it has seen any of them.
• NumaNode is an opaque u32 newtype built with an inherent const fn new(u32).
• Nothing reaches a consumer's dependency graph; the only manifest entry is a test-only
  dev-dependency. The std feature is on by default and adds implementations for HashMap,
  Path and PathBuf. With default-features = false the crate needs only alloc and
  pointer-width atomics; Thread then loses its thread id and cannot be constructed, leaving
  Owner and NumaNode readable so a no_std library can still implement the trait.
• docs/DESIGN.md records why the crate is split out, and the rules that let Thread gain
  coordinates later without breaking callers or changing behaviour.
  docs/STABILIZATION.md records the stable boundary.

Why Owner assigns its own identity

Callers used to choose the number, and the documentation warned at length that a collision
was "worse than a slowdown" and that keeping owners distinct was the embedding application's
problem. Taking the identity from a process-wide counter removes the hazard outright rather
than documenting it. Equality and hashing use identity alone.

min_threads is a floor, not an estimate. 0 means the runtime promises none and spawns on
demand, which falls through HashMap::with_capacity as a no-op, so both cases share one
expression at the call site. It was named threads_hint first; in std, _hint already means
a bound — size_hint returns a lower bound plus an optional upper, and overshooting is a bug
— so "hint" would have contradicted the suffix while leaving 0 a magic value.

Why the ids take new rather than From<u16>

A From<integer> impl on a permanently stable type is a one-shot commitment. Every way of
evolving one is breaking, verified against rustc:

cargo semver-checks 0.48 reports "no semver update required" for all three, so none of them
would be caught in review. NumaNode is therefore u32-backed with an inherent new. The
accepted width already exceeds any node count real hardware reaches — Windows' own topology
APIs report NUMA nodes as USHORT — and a wider or fallible constructor can still be added
later under a different name without touching existing callers.

Provided implementations

Containers forward to what they hold; primitives and other types with nothing tied to a
thread get an empty implementation. Three cases are deliberately absent:

• References (&str, &Path) — relocating through one would adapt something the value
  only borrows, and whoever owns it is relocated on its own account.
• Cow — relocating a borrowed one has to clone it into owned storage first, which is
  too much work to hide behind an advisory call. It can return later if a caller wants it.
• Arc and sets — whether a shared allocation should split per thread depends on what it
  holds, and mutating a set element could change its hash and corrupt the container.

Naming

thread_aware_core::Thread shares a name with std::thread::Thread but is a different kind
of thing: an immutable coordinate that owns no OS resource. Importing both unqualified is
E0252, and both expose an identical id(&self) -> ThreadId. This is called out in the crate
docs and in a # Relation to std::thread::Thread section on the type. Raised deliberately
here in case reviewers would prefer a different name.

Scope

thread_aware is unchanged and still ships its own Affinity-based API. Nothing depends
on thread_aware_core yet; adoption is left for a later change. The diff against main is
the new crate plus its workspace wiring (Cargo.toml, Cargo.lock, CHANGELOG.md,
README.md) and nothing more.

Validation

• 25 unit tests and 14 doctests with --all-features; 25 unit tests and 12 doctests with
  --no-default-features. One doctest is ignored: it demonstrates
  #[derive(ThreadAware)], which lives in thread_aware, and compiling it here would
  require the dependency the example exists to argue against.
• Clippy in both feature configurations, rustdoc with -D warnings --cfg docsrs, formatting,
  spelling, and the generated README all pass.
• Static assertions pin the auto traits (Send, Sync, Unpin, UnwindSafe,
  RefUnwindSafe) on all three public types, and assert_obj_safe! pins dyn-compatibility of
  ThreadAware. Both guard silent regressions: a coordinate added later that is not Sync
  would strip that property with no signature change, and a defaulted-but-generic trait method
  would keep every impl compiling while breaking every Box<dyn ThreadAware>.
• Documentation and API shape went through repeated independent model-backed reviews. Those
  found real defects rather than wording nits: a counter width that would wrap and reissue a
  live identity, a claim that ThreadId is the operating-system thread id (it explicitly is
  not), an equality claim that was false under no_std, and an Eq/Hash test that passed
  vacuously because it compared a value with its own copy.